בסופו של יום נכס ה IT המהותי הוא המידע שאנו מחזיקים; רשימת הלקוחות שלנו, רשימת החייבים ורשימת החובות, תוכנית עסקית וכיוצא בזה. אנו חייבים להבין שזו המהות. כל איש IT שהוקפץ בלילה כדי לשנות דו"ח להנהלה מבין שזו המהות של ה IT ואנחנו מבצעים מניפולציות לצרכים שונים (פיתוח העסק, שיווק, ניהול מלאי לקוחות וספקים וכיוצא בזה).
לתהליך השעבוד למידע אנו מודעים יותר או פחות.
לדוגמא: מהם מספרי הטלפון של 5 חבריך הקרובים ביותר?
אני לא יודע אותם בעל פה כיוון ש"מערכת הIT" שלי לניהול הנושא מספקת לי שירות מעולה (קוראים לה טלפון עם זיכרון) ומי שחווה השבתה של טלפון כאשר לא היה לו גיבוי מכיר את תחושת חוסר האונים והשעבוד שעליה אני מדבר.
והנה נתון: 60 אחוז מגופים שחווים איבוד מידע פושטים את הרגל תוך כחצי שנה לאחר האירוע.
אז יש לנו מידע ומה אנחנו רוצים לעשות איתו? כמובן לשתף וקודם כל לשתף את המידע בין העובדים ומשם לשתף את מערכת המלאי שלנו עם הספקים ואת מערכת ההזמנות עם הלקוחות וכך הלאה. היכולת לשתף שהייתה קיימת בתוך הארגון ולצרכי עסק עברה למישור החברתי. יש לי חברים שאני יכול לזהות את הילדים שלהם ברחוב, למרות שמעולם לא פגשתי אותם, ראיתי אותם עשרות ומאות פעמים ברשתות החברתיות. השיתוף מביא לרוב, הגברה של היעילות (על הנזק של הדואר האלקטרוני לתפקוד יעיל נכתב רבות, אבל כמו כל כלי- צריך שיהיו לו כללים ואז הוא מועיל מאוד. הוא מקרב בין גופים מרוחקים פיזית או מחשבתית).
מה הן הדרישות שלנו מהמידע?
קודם כל שיהיה זמין. שיהיה לי את המידע בזמן שאני צריך אותו ומאחורי הדרישה הזו מסתתרת דרישה מאוד לא פשוטה מאנשי ה IT. מסחר בבורסה דורש מהירות של מאיות ואלפיות שנייה. עם הכניסה של חברות לאינטרנט השתנה לחלוטין תצורת התחזוקה. אם פעם היינו יכולים להשבית מערכות בערב או בלילה, כיום התחזוקה מצריכה מערך מתחלף בצורה שקופה ללקוח ולהטוטים שונים כדי לבצע תחזוקה בצורה מניחה את הדעת. סיכון ההשבתה מסיבות שונות אורב לנו ויש לנו צורך בתהליכים שיחזירו את מערך המחשוב לתפקוד
שנית, שיהיה אמין. מי שחווה עבודה משותפת על מסמך דרך הדואר עם יותר מ 4 אנשים מכיר את הסיוט של "מתי שלחת לי??", "לא, אני הורדתי את זה", "מה הגרסה עליה אנחנו מדברים????" וכך הלאה.
הייתי שמח אם סכום האחוזים בדוח האקסל יהיה 100 אחוז ולא 103 או 97. ואם אני מעלה נתוני לקוח, הטלפון שלו יהיה הטלפון הנכון ולא של לקוח אחר וכולי.
מידע זמין, אמין, חסוי וחשוף רק למי שחייב לראות אותו. אין דרך שאני מכיר להסביר למי שאינו איש מחשוב למה המידע שלו חשוף לחלק מאנשי ה IT בצורה די גורפת. התגברות המניפולציות על המידע (עולם כריית המידע) הביאה לכך שמופע יכול להתקיים במספר מערכות עם גורמים שונים שחשופים אליו. ועוד לא דיברתי על גיבויים ומערכות לפיתוח שאליהן גוזרים נתוני ייצור.
חלק מדרישות האלו אינן טכנולוגיות ואנחנו חייבים להתגבר על הנטייה לנסות לפתור בעיות בתהליכים בעזרת טכנולוגיה. לדוגמא- אם קיים תהליך שבו מדפיסים נתוני לקוחות, כנראה שמפעיל המדפסת יוכל לראות נתוני לקוח וכל ניסיון לחסום אותו ייצר בעיה חדשה בנושא הזמינות.
במאמר זה אתייחס לנושא חיסיון המידע:
טיפול בחיסיון הוא בשני מישורים הראשון הוא הגנה על המערכת מפני פריצה והשני הוא טיפול בגורמים שעובדים בתוך המערכות, לגבי נושא האבטחה של מערכות ה ITאין פתרון קסם (silver bullet) ויש לבנות תהליכים שונים בכל חברה (כל המשפחות המאושרות דומות זו לזו, כל משפחה אומללה בדרכה שלה- לב טולסטוי). כל עסק צריך לבנות את תהליכי ליווי
ה SDLC (Systems development life-cycle) לעצמו ואני אשתדל לסקור דרכים לבנייה ותחזוקה של התהליכים הללו בעתיד.
לגבי הטיפול בחיסיון מצד הגורמים המעורבים, אני אתייחס לעובדים בתוך הארגון ולא לשאר הגורמים (ספקים,לקוחות וכדומה), ההתייחסות לשאר הגורמים חשובה והיא שייכת לא מעט לנושא ליווי תהליך ה SDLC שהוזכר.
בתוך החברה שוב נחלק את הנושא לשני חלקים, הראשון מניעה והשני בקרה.
במניעה, השימוש הוא במתן הרשאות. בניהול הרשאות צריך להיזהר מגישת ה"לתת לכל אחד את ההרשאות שהוא חייב כדי לתפקד". גישה זו אומרת שניהול ההרשאות יהפך לסיוט אחד גדול עבור כלל המעורבים. איש ה IT, העובדים, הספקים, הלקוחות וכולי. בחברה של 30 עובדים עם 150 לקוחות אנחנו מגיעים ל 4,500 הרשאות כאשר לכל אחד תינתן הרשאה של קריאה או קריאה וכתיבה או ללא הרשאה והמהדרים מוסיפים גם מחיקה והנה קיבלנו 18,000 הרשאות בעסק לא גדול (ילדים,היזהרו מעצי הבאובב – הנסיך הקטן).
בואו נדבר על איש IT מושלם עם 5 אחוז טעויות וקיבלנו 900 הרשאות שניתנו שלא כשורה (רוב אנשי ה IT כולל עבדכם הנאמן מחזיק ממוצע טעויות גדול יותר). ולכן השיטה הנכונה היא לעבוד בפרופילים של הרשאות ולמעט בהרשאות נקודתיות. (בתהליך מתן הרשאות נקודתיות ניתן להשתמש לנושא ספציפי מאוד עם מיעוט משתמשים).
לדוגמא: המנכ"ל ומנהל הכספים רוצים ספריה משותפת וסודית משאר חברי ההנהלה.
מתן ההרשאות לא פותר את בעיית החיסיון. הוא מצמצם אותה ביעילות. וכאן אנו חייבים להבין שההגדרה שרק מי שצריך יראה את הנתון מתעלם מנקודה מהותית והיא שימוש המשתמש שמורשה (גרסת אבטחת מידע ל"גנן גידל דגן בגן").
האם בוחן פסיכומטרי בבקו"ם שסיים בדיקה של בת של אישיות ידועה ורץ לספר לחברה את תוצאות המבדקים שלה לא פוגע בחיסיון? ברור שכן. ולכן יש משמעות גם לשימוש המשתמש שמורשה.
כאשר יש זמינות לרשומות של אזרחים במשרד הפנים, בבנקים, במוסדות חינוך וכדומה על ידי חוקרים פרטים. כאשר חיפוש ריגול עסקי בגוגל מעלה מספר רב של חברות שעוסקות בתחום למחייתן. ברור שיש בעיה בתחום חיסיון המידע (הייתי עם אורח מחו"ל באלנבי והוא נדהם לראות קלטות פיראטיות, בגדי מותג מזויפים וכיוצא בזה נמכרים באין מפריע מול שוטרים בחנויות מסודרות ולא מתוך תא המטען של מכונית בסמטה אפלה).
ומתוך מה שנאמר- אתייחס כעת למסלול הבקרה, בניית תהליך רישום ובקרה של גישות למידע. אם אותו בחור בבקו"ם היה יודע שיש רישום של כל מי שחשוף לאותו מבדק ואם זה ידלוף החוצה יחקרו אותו הוא עלול להסתבך בצרות, הוא היה מהסס. לאחר שנים של ליווי אירועי אבטחת מידע , אני יכול להניח חד משמעית שמתוך Xמהססים לפחות אחד היה מבצע את המעשה למרות ההיסוס. וכאן באה חשיבות הרשומת ואמינות הרשומת.
בכל אירוע אבטחת מידע ההמלצה שלי לנאשם היא להכחיש. נטל ההוכחה בפשעי מחשב הוא כבד. יתרה מכך באם מי שעומד מול הנתונים אינו בקיא ערעור הביטחון של התביעה קל בהרבה מביסוס נתוני התביעה.
ניקח לדוגמא מערכת לניהול נושא סודי כלשהו עם 10 משתמשים, כל המשתמשים מזדהים עם מפתח זיהוי פיזי ייחודי, אישי ובלתי ניתן להעברה. והנה ראינו שאבי רון נכנס והוא היחיד שהיה חשוף לנתון שהתגלה אצל המתחרים. אני יערער על האירוע בתחילה מול מישהו שלא בקיא ולאחר מכן מול מישהו שבקיא.
לגבי טיעונים מול טכנופוב, אבי בא ואומר דבר פשוט, המערכת מחוברת לרשת שמחוברת לאינטרנט. ואם לפנטגון ולכור האיראני ולחברות אבטחה שונות הצליחו לפרוץ, הטענה שאנחנו כאן עשינו מערכת בלתי פריצה מגוחכת. וכן נכון שראיתי את הנתון אבל מי ערב לכם שלא הייתה כאן פריצה? כל ניסיון להביא נתונים כגון תעבורת הרשת, נתוני ה FW וכך הלאה רק יחזקו את טענת הפריצה החכמה. יש חוק שטענת קונספירציה טובה חייבת לקבל עזרה והעזרה הכי טובה היא שיבואו מומחים מטעם "הרשויות" וינסו למוטט את הטענה. נחיתת ארמסטרונג על הירח, רצח קנדי, אזור 51 וכך הלאה- כולם הוכחשו במרץ על ידי הגורמים הממשלתיים וכך קיבלו את אמינותם. ועכשיו לגבי שופט בעל ידע, אבי בא ואומר שזה לא היה הוא אלא מנהל המערכת. למנהל המערכת יש את כל היכולות בעולם "לגלגל" את האשמה על מי שירצה והטענה הזו מטרידה אותנו הרבה יותר.
צריך שיהיה רישום לגבי גישה בתוך מערכת, אולם הפתרון לבעיית החיסיון הוא במערכות למניעת זליגת מידע ( DLP - Data loss/leak prevention ). מערכות למניעת זליגה מספקות רישום כללי לגבי גישה לנתונים ושימוש בהם. במקרה של אבי ניתן היה לשלוף את נתוני הגישה של מנהל המערכת ולראות אם הוא נכנס והעלה את הנתון המדובר.
אתייחס כעת לשני נושאים בתהליך הפריסה של מערכת למניעת זליגה.
כחלק מהותי מהטמעת מערכת למניעת זליגה עולה נושא האחריות לטיפול. אם מנהל ה IT יבוא ויאמר שמתוך החלטה של עלויות מול תועלות, אין לו את המידע מי ניגש, הוא יצטרך להסביר ולנמק את ההחלטה של עךויות מול תועלות. אם תוטמע מערכת DLP ובבוא יום יתברר שהמידע לגבי מנהל הרשת נרשם ולא נעשה איתו דבר, הסיכוי שלו להישאר בתפקידו הולך וקטן משמעותית (המרוץ של מנהלי אבטחת מידע להוסיף מערכות אבטחה ללא ניטור בזמן אמת מסביב לשעון מכניס אותם יותר ויותר לתוך המלכודת הזו).
נושא נוסף שהטמעת מערכות למניעת זליגה מעלה לפני השטח הוא בעיית "ניקוי השולחן". עובדים שמחליטים לעזוב לוקחים איתם לפני העזיבה לא מעט דברים. אחד מהדברים שרובם לוקחים הוא את המידע שאליו היו חשופים במהלך עבודתם. לפעמים זו תיבת הדואר שלהם, לפעמים זו ספרית המסמכים של המחלקה או של החברה. רוב מערכות ה DLP מתריעות על כך. באם הנושא לא מטופל מיידית, הסבירות שהחומר "יוחזר" אפסית. אין שום ערובה שהעובד לא ישמור לעצמו עותק. גם אם ימצאו שופט ויתבצע חיפוש אצל העובד- הוא יכול לשמור את החומר ב DOK, באינטרנט, על הטלפון הסלולארי וכך הלאה. אירוע ניקוי שולחן חייב להיות מטופל מיידית.
ההבנה שעסק חייב בטיפול מיידי באירועי אבטחת מידע כגון גניבת מידע, והיא לא חייבת להיות גוף ענק כדי להחזיק מוקד, הביאה אותי לנסות ולהביא את שירותי המוקד גם לחברות שאין להם מיליוני שקלים בשנה להחזיקו.
החבילה הבסיסית ביותר שאני מציע ללקוחותיי, היא חבילת הגנה מפני זליגת מידע עם בקרה ב real time ע"י מומחי אבטחת מידע, 24 שעות ביממה.
רעות מירון
מנהלת שיווק | שנת ישרים
